Network processors (NP) are specifically designed to perform packet processing. Conventionally, network processors may be used to perform such packet processing as a core element of high-speed communication routers. In order to address the unique challenges of network processing at high speeds, modern NP generally have a highly parallel multi-processor architecture. For instance, the Internet exchange processor (IXP) series, which belongs to the Intel® Internet Exchange™ Architecture (IXA) NP family, include NP that process packets using a micro-engine cluster. The micro-engine cluster may consist of multiple micro-engines (programmable processors with packet processing capability) running in parallel.
However, in contrast to the highly parallel multi-processor architecture utilized by network processors, traditional network applications are easily coded using sequential semantics. Generally, such network applications are typically coded to use a unit of packet processing (a packet processing stage (PPS)) that runs forever. Hence, when a new packet arrives, the PPS performs a series of tasks (e.g., receipt of the packet, routing table look-up and enqueuing on that packet. Consequently, it is usually expressed as an infinite loop (or a PPS loop) with each iteration processing a different packet.
Hence, there is a large gap between the parallel architecture of network processors and the sequential semantics of network applications. One way to address this problem is to adapt the paradigm of parallel programming for coding traditional network applications. As known to those skilled in the art, parallel program involves partitioning the application into subtasks, managing the synchronization and communication among the different subtasks and mapping the various subtasks onto a multi-processor system. Unfortunately, such a parallel programming paradigm is untraditional and not familiar to many.